In OpenFlow based networks each OpenFlow-enabled switch is configured to act according to so called OpenFlow rules OFR, installed by means of a OpenFlow protocol. Such an OpenFlow rule is defined by a match set, an action set and a rule priority. The match set defines to which network flows the action set is applied. The action set defines elaborations and forwarding decisions for incoming flows matching all the conditions in the match set. The rule priority is used to order a rule relatively to other rules installed in the OpenFlow switch. The network behavior is then defined by the combination of all rules installed at all OpenFlow-enabled switches and the topology of the network, i.e. the shape of the OpenFlow switches physical interconnections.
For example when an OpenFlow rule in a given OpenFlow switch is installed it may interact with a number of other rules installed in other OpenFlow switches depending on the network topology. A rule installed in an OpenFlow switch can make useless other rules installed in other OpenFlow switches along a certain network path. The presence or absence of such interactions between rules on different OpenFlow switches influences the behavior of the network in general. For example interactions may generate wrong behavior in the network. Such rule interactions are very difficult to detect since the total number of rules involved in an OpenFlow network, in particular in a big network, and the number of resulting possibilities of combining them according to the network topology is huge.
To help to define or program OpenFlow rules the language, called “Frenetic” may be used, which is a high level language based on functional programming paradigm. After programming the OpenFlow rules on the high level the rules are translated into a set of lower level packet processing rules, however, they are limited to a single OpenFlow switch. Interactions among the rules are solved on the high language level.
However, this has the disadvantage that once an OpenFlow switch has been provided with rules any amendment of the rules like port changing of forwarding rules, etc. may result in further interactions which cannot be solved anymore, if for example a decompiler is not present or another user does not have any tool for decompiling the installed rules in the Frenetic language.
It is therefore an objective of the present invention to provide methods and systems for determining network-wide interactions between forwarding elements.
It is a further objective of the present invention to provide a method and a system for detecting interactions on a single forwarding element
It is an even further objective of the present invention to provide a method and a system for detecting interactions in a network which are more flexible.
It is a further objective of the present invention to provide methods and a system for detecting network-wide interactions between forwarding elements in a network which are easy to implement while being reliable.
It is an even further objective of the present invention to provide methods and a system which reduce network resource consumption, in particular memory in the forwarding elements as well as processing load on the forwarding elements.
It is an even further objective of the present invention to enable analyzing of network-wide interactions.
It is an even further objective of the present invention to classify interacting rules.